Summary

Fixes a bug where editor.getTitleAndContent() could return JavaScript objects instead of plain strings to the native host app, corrupting the content in the host app.

Root Cause

WordPress's Gutenberg data store has an architectural inconsistency in how getEditedPostAttribute handles values from the edits layer vs the base entity record.

When a post is loaded, title and content are stored as { raw: "..." } objects in the entity record (this is the shape getPost() in bridge.js constructs). Two different normalization paths exist:

1. Base record path (no user edits): getEditedPostAttribute('title') → getCurrentPostAttribute → getCurrentPost → getRawEntityRecord (extracts .raw) → then getPostRawValue is applied — returns a plain string. ✅
2. Edits path (after any code calls editEntityRecord): getEditedPostAttribute('title') → edits[attributeName] — returns whatever was stored in edits, with no normalization. ❌

The edits reducer stores values verbatim:

case 'EDIT_ENTITY_RECORD':
    const nextEdits = { ...state[action.recordId], ...action.edits };

So if anything dispatches editEntityRecord('postType', type, id, { title: { raw: '...', rendered: '...' } }), the {raw, rendered} object goes directly into edits.title, and getEditedPostAttribute('title') returns the object — bypassing getPostRawValue entirely.

Similarly, getEditedPostContent() has a code path that returns record.content from getEditedEntityRecord without normalization — if the content in the edits layer is an object, it passes through as-is.

When does this happen in practice?

• Undo/redo: The undo manager stores { from: editedRecord[key], to: edits[key] }. If at any point the edited record contained a {raw, rendered} object, undo replays it as an edit — re-introducing the object.
• Any internal Gutenberg code that calls editEntityRecord with REST API-shaped data rather than plain strings.

Confirmed via E2E

We confirmed this by injecting {raw, rendered} objects via editEntityRecord in a Playwright test and then calling getTitleAndContent(), verifying the bridge returns plain strings (i.e., normalizeAttribute() catches the object before it reaches the host). The underlying getEditedPostAttribute('title') selector does return the object in this scenario — confirmed separately during reproduction testing.

We could not reproduce the bug through normal user interactions (typing, undo/redo, cache invalidation, REST API re-fetches) — the standard Gutenberg code paths happen to always produce string edits. The bug requires an internal code path that dispatches object-shaped edits, which is a Gutenberg data store implementation detail outside our control.

The Android/iOS host apps are not the source

Both the Android (GBKitGlobal.Post.title: String) and iOS host apps pass plain strings to GutenbergKit. The WordPress Android app (WordPress-Android) also decomposes {raw, rendered} from the REST API into plain strings via FluxC PostModel before reaching GutenbergKit. The issue is entirely within the JS data store layer.

What We Explored

1. Making native types match the {raw, rendered} shape

We initially updated iOS and Android to parse {raw, rendered} objects. This worked mechanically, but rendered is useless client-side — it's only available from the server's initial REST API response and becomes stale after any edit. The server-side rendering pipeline cannot be reproduced in the client.

2. Hoisting the {raw, rendered} wrapper into native input types

We considered having EditorConfiguration accept {raw, rendered} objects. But the data store replaces them with plain strings after edits, so output normalization would still be needed — making the input change pure overhead.

3. Using getEditedPostAttribute('content') instead of getEditedPostContent()

For 'content' specifically, getEditedPostAttribute delegates to getEditedPostContent() — same code path, same bug.

Fix

Add a normalizeAttribute() function at the JS bridge boundary that extracts .raw from objects or passes strings through unchanged. Applied to both title and content in getTitleAndContent(), and to block content in appendTextAtCursor(). Also applied defensively to the initial postTitleRef and postContentRef initialization.

function normalizeAttribute( value ) {
    if ( value === null || value === undefined ) {
        return '';
    }
    if ( typeof value === 'object' ) {
        return value.raw ?? '';
    }
    return String( value );
}

Also removed the redundant getContent() bridge method (and its iOS public API) — getTitleAndContent() is now the single accessor for reading editor state.

Note: The removal of getContent() from EditorViewController is a breaking change for iOS consumers. Use getTitleAndContent() instead.

Changes

• src/components/editor/use-host-bridge.js: Add normalizeAttribute(), apply to getTitleAndContent() and appendTextAtCursor(), defensively normalize ref initialization, remove getContent()
• src/components/editor/test/use-host-bridge.test.jsx: Unit tests for normalization edge cases (null, undefined, objects, arrays, primitives), changed flag correctness, and appendTextAtCursor with object-shaped and string block content
• e2e/get-title-and-content.spec.js: E2E tests covering plain string return in all states, including regression tests that inject {raw, rendered} objects via editEntityRecord and verify getTitleAndContent() normalizes them with correct changed flag behavior
• e2e/editor-page.js: Add getTitleAndContent() helper to page object
• ios/.../EditorViewController.swift: Remove getContent() public API (breaking change)
• ios/.../EditorViewControllerDelegate.swift: Update doc reference

Test Plan

• JS unit tests pass (15 tests)
• ESLint passes
• E2E tests pass (6 tests) — including regression tests that reproduce the bug by injecting {raw, rendered} objects into the data store and verifying normalizeAttribute() returns plain strings with correct changed flag
• iOS Swift package builds